Jira
Pull Request

故事背景

KIP-405引入了 Remote storage 讓偉大的 Kafka 再次偉大， Remote storage 允許 Kafka 將資料保存在遠端的儲存系統上，不只達到一定程度的運算/儲存分離，更能在儲存這層達到無縫的擴展，大家可以想想以前Kafka節點的硬碟空間不夠時的惡夢 ...

然而就像人不會只有優點，任何的技術改進同時也會引入新的技術障礙。以前資料在本地硬碟時，要查詢資料的任何資訊都是相當容易，但當資料被放在遠端之後呢？網路本身帶有延遲未知的特性，同時我們也無法確定其他系統的可用狀況，換言之，原本只要跟本地檔案打交道就能完成的操作，現在也必須要跟遠端的系統互動才能完成

而我們今天的主角就是 LIST_OFFSET 這個操作，什麼是 LIST_OFFSET? 顧名思義，這隻 APIs 就是用來查詢符合條件的資料的 offset 是多少，例如常見的幾種操作：

1. earliest offset：回傳現有資料中最小的 offset
2. latest offset：回傳現有資料中最大的offset
3. max timestamp offset：回傳現有資料中有最大 timestamp 的 offset
4. timestamp offset：回傳符合 timestamp 資料們的最小 offset，例如有三筆資料符合你指定的timestamp，則會回傳這三筆資料中最小的 offset。
5. latest tiered: 回傳在遠端系統中資料的最大 offset
6. local earliest offset: 回傳本地資料中最小的 offset，注意喔，這個跟第一種 "earliest offset"不一樣喔

相信聰明的讀者看到這裏，已經可以想到資料在遠端時會發生的問題了，沒錯，那就是有些資料在遠端該怎麼辦？相信聰明的你一定也想到解決辦法了，那就去遠端系統查資料阿！當然我們都是話會說手會做的好工程師，我們就來一起思考如何處理遠端操作產生的額外延遲！

一秒
兩秒
三秒

好，接下來進入這個解法

解決辦法

KIP-1075 提出一個善用 Kafka 機制的解決辦法，那就是將 LIST_OFFSET 緩存在 Purgatory (也許未來會在某篇廢文中解釋，但可想成一個神祕的黑盒子提供處理 delayed operations 的工具)，並透過新增的 remote read threads 來處理遠端資料的查詢，同時使用者也可以設定每個 LIST_OFFSET 的超時上限。這樣設計有幾個好處：

1. remote read thread 會接手 LIST_OFFSET，因此本來處理請求的執行緒可以安心去處理其他事情
2. Purgatory是一個強大的機制，可以確保每個 delayed operations被照顧的很好
3. timeout 的設定讓我們安心的把鍋丟給使用者

後續討論

前面提到六種 offset 查詢方式，忘記的人趕快往上滑一下。大家有沒有注意到有兩種查詢其實是有點麻煩？給個提示，Kafka 的索引是基於 offset .... 一秒兩秒三秒，沒錯，就是你腦袋想的那個，基於 timestamp 來查詢 offset 很麻煩， timestamp 並不是索引的一部分，所以只要涉及到 timestamp 的查詢一律都會牽扯到輪詢一大堆資料的事情，如果對這個後續好奇，除了可以等待文章更新以外，也可以關注KAFKA-15859討論串

廣告
歡迎訂閱全臺最鬆散的開源社群源來適你，上面不定期會有各種開源的廢文。也歡迎參加全臺最鬆散的開源討論頻道，上面有一群網友一起在刷開源技術